home *** CD-ROM | disk | FTP | other *** search
/ SuperHack / SuperHack CD.bin / CODING / MISC / STRATEG3.ZIP / SITUATIO.AI < prev    next >
Encoding:
Internet Message Format  |  1994-12-12  |  4.5 KB
  1. From: empath@umcc.umich.edu (Tim Triemstra)
  2. Subject: Game AI posts:
  3. To: jon@stekt.oulu.fi
  4. Date: Mon, 12 Dec 1994 03:18:15 -0500 (EST)
  5.  
  6. <re-cap of Tim Triemstra's postings from rec.games.programmers>
  7. <with respect to "situation objects" in designing an AI system>
  8. <re-written for general availability on December 11, 1994>
  9.  
  10. <Tim can be reached at empath@umcc.umich.edu>
  11. ================================================================
  12.  
  13. A method for handling computer intelligence that I'm using is a
  14. little simpler to implement than neural-nets: not necessarily
  15. better or worse, maybe just "different."
  16.  
  17. All units in any type of strategy game have limitted situations
  18. that they can be put into (the broader the definition, the
  19. smaller the number.)  IE: If you have a game with 10 tanks on
  20. each side it could be said that there are only 11 possible
  21. situations: 1 situation for each number of tanks visible to the
  22. player and 1 situation where none is visible.  Of course, that
  23. is too broad to really _do_ anything with.  To be of any real
  24. value the situations must take into account strength, ranges
  25. and other aspects of the situation.
  26.  
  27. Since I have a smaller number of units in my game, I make little
  28. "situation objects" composed of all the various possible
  29. situations.  Each situation object also contains the orders to
  30. give to the player.  The orders are executed if it is determined
  31. that this particular "situation object" is the best match for
  32. the current state of the player.  The higher the number of
  33. possibilites, the greater the intellect of the computer
  34. controlled player.
  35.  
  36. To me, this was much simpler than hand-coding a tree because I
  37. could make a move construction kit that builds these situations
  38. and the resultant decision and saves them into a library.  Beta
  39. testers can help build them too.
  40.  
  41. <... end of message #1 ...>
  42.  
  43. > Wait, so you build a (let's call it) a data base for each
  44. > instance of tank vs other tanks and then a "good" solution for
  45. > it???  Wouldn't that be huge?
  46.  
  47. Yes, in a SSI wargame it would not be a viable solution.
  48. However, in my game (and I'm sure many other people's) there are
  49. limitted types of units and limited quantities of units in each
  50. mission or scenerio.
  51.  
  52. In my game, there are only 5 units (I may merge them down to 3
  53. total types of units) which can have various attributes (larger
  54. weapons, higher speeds etc.) but those factors are taken into
  55. each database, or "situation object" entry.
  56.  
  57. In my early designs, only 30 or so data elements is needed for
  58. each unit type to give what appears to be nearly adequate
  59. responses.  I also curb the results slightly by giving units
  60. commands like "move here stealthy" or "move here while attacking
  61. whomever you see" to stack the deck in the decision making.
  62.  
  63. Mind you, this idea of "situation objects" is purely one way to
  64. do it that may be practicle in some gaming situations.  I'm not
  65. a big fan of simulations (like SSI games) and hence wouldn't do
  66. a game like that.  Those SSI games couldn't use my idea, but
  67. Dune II could (and it would actually be smarter :)
  68.  
  69. <... end of message #2 ...>
  70.  
  71. Welp, the idea of finding the nearest "situation object," as I
  72. sometimes refer to it, isn't nearly as difficult as you may
  73. think.
  74.  
  75. First off, these objects are based completely on "relative
  76. situations"  ie: if a guy is stronger and to the upper-left
  77. of the character then that would be one situation.  So, the
  78. tree goes something like this:
  79.  
  80. 1) How many opponents are visible?
  81.  ( branch to the decision objects sorted for each answer )
  82.  - branch if 1 or more
  83. 2) How many can hit me within X moves
  84.  - branch if safe to not run
  85. 3) How many can I hurt?
  86.  - branch if any
  87. 4) _SHOULD_ I try to hit him or run
  88.  - branch if try to hit
  89. 5) Which is most benefical to hit
  90.  - branch etc...
  91.  
  92. Now, in my particular game, each unit is also given priorities
  93. that factor into this decision.  So, you may tell a unit to
  94. scout but give him the order to engage or hide, this of course
  95. adds weight to different tree decisions.
  96.  
  97. The major advantage of a system like this, as I said, is that
  98. you can make the AI as good or bad as you like.  Quite frankly,
  99. I'm under the opinion that a "game" does not need particularly
  100. good AI to be a good game.  Simulations (not my favorite) are a
  101. different story.  A game need only provide an enemy adequate
  102. enough to give the player some fun and to enact the plot.
  103. Dune II (my favorite example) has horrible AI, and anyone can
  104. eventually beat the game, but it is unquestionably enjoyable to
  105. play.
  106.  
  107.  
  108. -- 
  109. Tim Triemstra ... Empath Software .... Empath@umcc.umich.edu
  110. <><><><> If'n you ain't the granddaddy of all liars <><><><>
  111.